In a current communications network, as a quantity of users rapidly increases, service models get diverse, and networking becomes complex, a risk of service traffic impacting a communication device increases accordingly. When a volume of the service traffic is beyond a load capability designed for a communication device system, congestion in a large area and a decrease of a call completion rate are usually caused to a communication device, and a communication device fault is even caused. To ensure system stability upon heavy traffic in various service traffic-intensive scenarios, a traffic control technology becomes a research hotspot.
According to a difference of locations of a traffic-control-protected object and a traffic control executor in a network, Internet Engineering Task Force (IETF) Request for Comments (RFC) 6357 classifies traffic control into three types: hop-by-hop, end-to-end, and local overload control. Referring to traffic control models of the three types shown in FIGS. 1A to 1C, FIG. 1A and FIG. 1B belong to network traffic control, in which a front-end network element on a network path controls, according to a load status of a back-end network element, a volume of traffic sent to the back-end network element, for example, in FIG. 1A, the front-end network element A receives a load status of the back-end network element B via a link 101 to process a volume control of traffic sent to the back-end network element B; similarly, the front-end network element B receives a load status of the back-end network element C via a link 102 to perform a volume control of traffic sent to the back-end network element C; in FIG. 1B, the front-end network element A receives a load status of the back-end network element C via a link 201 to perform a volume control of traffic; and FIG. 1C belongs to network element traffic control, in which an overloaded network element controls an actually processed traffic volume according to a resource load status of the overloaded network element, and rejects or discards a service message that is beyond a processing capability of the network element.
In comparison, because traffic control is performed on the front-end network element with respect to the network traffic control, less resources of the back-end network element are consumed, and end-to-end traffic control efficiency is higher. In addition, if the back-end network element has a load-sharing network element, the front-end network element may conveniently distribute a service message that is beyond a processing capability of the back-end network element to the load-sharing network element of the back-end network element, thereby improving network resource utilization and a service success rate. Therefore, a network traffic control model is mainly used in traffic control in the prior art.
In the network traffic control, the back-end network element notifies the front-end network element of an overload message, and the front-end network element determines an overload degree of the back-end network element according to a frequency of sending the overload message by the back-end network element, and finally, determines a volume of traffic that needs to be rejected or discarded; or, the back-end network element calculates a service interval/service speed according to the load status of the back-end network element, and instructs the front-end network element to perform traffic control; or, the back-end network element calculates a traffic control allowed proportion or a traffic control rejection proportion according to the load status of the back-end network element, and instructs the front-end network element to perform traffic control.
It can be learned from the foregoing description that, in the prior art, the front-end network element does not perform overload control according to a load status of a service message of a different type in the back-end network element, causing a problem that traffic control is performed on a non-overloaded service message.